Arrangement and a method relating to session management in a portal structure

ABSTRACT

The present invention relates to a portal structure providing end user stations ( 5 ) with access to services/applications ( 26 ), comprising a portal core ( 1 ) and a number of services/applications ( 26 ). The portal core comprises a presentation arrangement, portal session managing means ( 13 ) generating session related information, e.g. session identifications and portal storing means ( 51 ) for storing session related information. At least some of the services/applications ( 26 ) are external with external session identifications. Session unifying means ( 50 ) are provided for mapping between portal session identifications and external session identifications. For communication between the portal core ( 1 ) and external services/applications ( 26 ), the external identification is used, whereas, in communication between an end user station ( 5 ) and the portal core ( 1 ), only the portal session identification is used.

This application is related to U.S. patent application Ser. No.10/466,605, filed on Jul. 18, 2003; U.S. patent application Ser. No.10/470,224 filed on Jul. 24, 2003; and U.S. patent application Ser. No.10/470,221 filed on Jul. 24, 2003, the disclosures of which are fullyincorporated herein by reference.

TECHNICAL FIELD

The present invention relates to session management and portalstructures, particularly Internet portals, providing end user stationswith access to services/applications. The invention also relates to anarrangement in a portal structure used for session management. Theinvention further relates to a method of session management in a portalstructure for end users accessing services/applications via said portalstructure.

The invention particularly relates to handling of session managementwhen different entities, such as portals, services or application aremanaged by different session management means.

BACKGROUND OF THE INVENTION

When referring to a portal is generally meant an Internet portal.Internet portals interacting with end users usually provide for sessionmanagement in order to be able to track and keep control of theactivities of the end users, and in order to store end user specificinformation, like authentication status, information, such as lists andorder of initiated actions and resulting events etc. Today a portaloften needs to be able to integrate functionality of other softwaresystems or even other portals. However, sometimes such other systems,such as services/applications or other portals, have their own sessionmanagement. This means that in one way or another session management asprovided for by different session managing means needs to be integratedor combined.

There is also an increasing need to personalize or customize the way anend user can access services irrespectively of the actual location ofthe services or applications, or who is the provider. Also the demandfor access to mobile Internet services gains importance, i. e. that endusers may want to be able to, in a rapid and uncomplicated manner, getaccess to services from any end user station, i. e. also from mobiledevices; it may e. g. relate to sending and receiving e-mails, shortmessages, accessing web-based information from mobile as well as fromfixed end user devices in a user-friendly, quick and simple manner. Thisis called the mobile Internet.

Browsing using a mobile device is however more difficult than browsingusing a PC, since the mobile device, as compared to the PC, has limitedinput and output capabilities. Thus, this means that it gets even moredifficult to provide mobile end users with a satisfactorypersonalization, and management of services as well as sessionmanagement get even more complicated. Anyhow, there is an increasingdemand on behalf of the end user to always be able to accessapplications and services. A portal is such a doorway to the content ofservices and applications which particularly should be tailored to suitthe end user preferences.

Examples on portal content are information services (also including pushcontent which relates to an Internet technique through which allinformation a user subscribes to automatically is provided to the user,or information that the service provider or operator means that the usershould be provided with). Examples on information services are weatherforecasts or weather information in general, commercial services such asshopping malls, or generally any kind of information, multimediaservices such as streaming audio/video, games, instant messaging andnewsgroups, web based mall, access to particular communities throughchat-rooms. It is also desirable to be able to provide appealinggraphical user interfaces for representing applications and menus on PC:s, and particularly also for WAP enabled devices, in case a portal ismobile. Much effort is also put down on personalizing the structure andthe content of personal portals, and to provide a possibility to controlthe interaction and behaviour of individual services and applications,by setting personal preferences. It is however difficult to provide forsatisfactory access possibilities irrespectively of which kind of devicethat is used by an end user. Particularly when different systems need tobe integrated, as far as session management issues are concerned, i. e.when the different systems (portals, services/applications, otherportals etc.) have their own session management, the situation may getvery complicated.

Until now many applications are in principle exclusively designed forthe 2G telecommunications environment and they have been implemented asmonolithical blocks or with a proprietary service network to handle thespecific QoS requirements for the respective applications. This has aconsequence that such applications work satisfactory as isolatedapplications, but they are difficult to integrate with otherapplications developed in similar ways. Applications developed for theInternet (Internet protocol) environment have to a large extent beenbased on established and open de facto standards supporting extensiveintegration of different applications. Many such standards have beenused in the 2G environment for non realtime critical applications.However, through the introduction of 3G networks (3GPP), futureapplications will contain a mixture of telecommunication anddatacommunication services, mixing higher and lower bit rates as well asreal time and non-real time traffic. The service networks of today arenot designed to handle such mixtures, nor are the existing IP-basedapplications designed for the specific characteristics concerningwireless networks. As can be seen there are many complicating factorsconcerning the provision of satisfactory access for end users toservices, particularly when session management is handled by differentsession managers for different systems/entities.

Session management of homogeneous portal environments can be clearlyspecified and may for example be performed based on the servlet sessionAPI (Application Programming Interface) specification or the session EJB(Enterprise Java Beans) specification. These specifications define thebasic operations for session management, namely to create/destruct asession and to get, set and remove a key-value pair in a constructedsession.

Internet portals are usually provided with a session management systemallowing tracking of the actions initiated by an end user. Such actionsmay for example include the actions end user entering the system,authentication of the end user, access by the end user to a portalservice etc. As long as the end user navigates within the portal, i. e.requests access to services/applications internal to the portal, whichhere means services/applications for which session management is handledcentrally within the portal, session management can be handled easily,since every portal service can ask a central session manager, i. e. theportal session managing means, to retrieve information stored in thesession of the end user. The sessions are particularly stored in storingmeans. However, the situation is different if an end user requestsaccess to an external system or to a service or an applicationintegrated with the portal, or an external service/application, whichhere means a service/application having an external, or its own specificsession management. The situation can then be very complicated. Aserious problem is that, if a service or an application (or anotherportal), that an end user wants to access via a portal structure, hasits own session management, the external session management may beincompatible to the portal session management. This is often the casewhen application service providers offer services to portal owners. Forvarious reasons it may not be desirable to expose the external sessionmanagement to the end user. Still further the sessions created takinginto account also the external session management tend to get very long,i. e. the session identity that is used in communication with the enduser has to contain not only the portal session identity, but inaddition thereto also the external session identity. Often such lengthysession identifications can not be handled by the clients served by theportal. This is particularly serious if the end user station is a mobiledevice such as a WAP-device, which simply might not be able to handlesuch large amounts of data. Even for an end user station able to handlesuch amounts of data only for identification purposes, it involves awaste of resources and time.

SUMMARY OF THE INVENTION

What is needed is therefore a portal structure through which sessionmanagement can be handled in an easy and efficient manner, also when thesession management of the accessed systems/services/applications ishandled by other, different session managing systems. Particularly, whena portal structure has its own portal session managing means and anothersystem, such as a service, an application or another portal, to which anend user requests access, has its own, here denoted external, orproprietary, session managing means, an easy and efficient sessionmanagement is needed. Particularly a seamless unification of sessionmanagement between portals and externally session-managed (external)systems is needed. A portal structure is also needed through which thesession management existing in other systems, such asservices/applications or portals that are session-managed by third partysession managing means, or external session managing means, can becombined and integrated with the portal session management.

An arrangement is also needed through which a portal (internal) sessionmanagement and various session management methods of third party orexternal session managed systems can be unified into a unified sessionmanagement. Particularly a portal structure is needed which is able toprovide an end user with access to services/applications for whichsession management is handled by external session managing means (thirdparty session managing means), i. e. not the same session managing meansas the portal session managing means as well as to internalservices/applications. An end user should thus be provided with accessto services etc. irrespectively of whether the services/applications(content) are located within the portal structure itself, or whether theapplications/services and the content thereof reside outside the portal,i. e. are provided by external providers and/or are session-managed byexternal session managing means.

Particularly a portal structure is needed which allows access by mobileend user stations (in addition to fixed end user stations)irrespectively of whether accessed services/applications etc. areinternally or externally session-managed. A portal structure is alsoneeded through which the number of parameters that have to be used incommunication with end users is reduced as compared to for hithertoknown structures, and irrespectively of whether accessedservices/applications reside within the portal or not, andirrespectively of whether they are separately or externallysession-managed. Particularly a portal structure is needed which iscapable of integrating different session management methods at the sametime as it integrates Internet and WAP-based services, so that access isenabled from any Internet connected PC, WAP-device or any other mobiledevice using any mobile access network.

An arrangement for handling and integrating session management in aportal structure is also needed through which one or more of the abovementioned objects can be fulfilled. Still further a method for handlingsession management in a portal structure is needed, as well as a methodof providing an end user with access to services/applications,irrespectively of whether they are session-managed by the portal sessionmanaging means or by external session managing means, through which oneor more of the above mentioned objects can be fulfilled.

By using a generic markup language in a portal, content of applicationsand services can be stored independently of user station or user device,and before showing the content of an application or a service, thecontent can be transformed into the format, i. e. the markup language,that can be understood by the end user device. One example on such ageneric markup language is the XML (Extended Markup Language). As astandard for navigation in an XML-based portal is the XLinkspecification used, which allows elements to be inserted into XMLdocuments in order to create and describe links between resources. XLinkprovides a framework for creating both basic unidirectional links andmore complex linking structures. It allows XML documents to assertlinking relationships among more than two resources, associate metadatawith a link and to express links residing in a location separate fromthe linked resources. XML is described in W3C Recommendation, 6 Oct.2000, Extensible Markup Language (XML) 1.0 (Second Edition), whichherewith is incorporated herein by reference.

In the following some concepts used in this document will be describedor defined. A portal is generally a non-physical entity in the Internetdomain which can be described as an “electronic publishing space” whichis owned by an individual or an organization, and which provides eitherdirect access to information and services, or links to other entities inthe Internet or private intranet domains, providing information andservices to authorized end users. A portal is in its simplest form aregular home page or a list of links, whereas in more advanced forms itmay offer interactive services, not only to those who consume what ispublished, but also to those who are granted the right by the editor topublish on the portal, as well as to the editor himself, regardingdifferent aspects on how the portal is used.

Wireless end users are given access through a “service” portal. Such a“service” portal is different from a traditional fixed Internet portalfor PCs, and end users demand personalized services delivered to, andpresented on, their mobile terminal at least as an option. In thefollowing will however not the terminology “service” portal be used, buta portal (structure) in this document means either a conventional portalor a “service” portal.

An application is one or several cooperating software entities, thefunctional focus being user interaction and usefulness for the end user.An application platform is a defined combination of software andhardware entities used to implement applications of a certain kind whichare characterized by the functionality and quality of its constituentparts.

By portal infrastructure is, in general terms, meant the software andhardware entities needed to either host or produce or generate aspecific portal. Specifically it contains a portal core, an IPinfrastructure and service enablers.

A service enabling means, also called a service enabler is a supportfunctionality accessed via APIs (Application Programming Interface)raising the abstraction level and simplifying the applicationdeveloper's task. A portal core is the core of a portal infrastructure,i. e. a portal core is the central part of a portal structure that isneeded to develop a portal framework within which content andapplications can be disclosed and accessed by end users in a controlledand unified manner. By a service network is generally meant an IP-basednetwork, which consists of nodes hosting application servers, servicecapability servers, application support servers, IP infrastructureservers etc. Application support servers interface with service networkresources or other external resources than core networks, whereasservice capability servers interface with resources and functionality incore networks.

In the present application a portal structure is intended to mean aportal core, a plurality of services and applications with their contentand service enabling means (service enablers). Generally may also theconnectivity and data bearer functionality be included. However,important for the functioning of the present invention are thecomponents of the portal core. The problems to be solved areparticularly present when accessed services/applications aresession-managed by other means than the session managing means of theportal structure itself.

Therefore the invention provides a portal structure, providing end userstations with access to services/applications which comprises a portalcore (and service enabling means, connectivity means via which end useraccess is provided). The portal core comprises a presentationarrangement, a portal session managing means generating and handlingsession related information, e. g. session identifications, and storingmeans for storing session related information. The portal core alsoincludes subscriber managing means, not further described. At least someof the services/applications comprise external services/applicationswhich are session-managed by external session managing means generatingand handling external application/service session related information,e. g. external session identifications.

The portal session managing means comprises a session unifyingarrangement for mapping or transforming between portal sessionidentifications and external service/application session identificationinformation. For communication between the portal core and externalservices/applications, the external service/application external(proprietary) session identifications are used, whereas forcommunication between an end user station and the portal core, only theportal session identifications are used. Particularly theservices/applications generate a generic markup language which, evenmore particularly, may be the XML language.

In advantageous implementation external session identificationinformation for all external services/applications active in a sessionis stored in the portal storing means, at least throughout the durationof the respective session, or throughout a predefined time period. Atime period may e. g. be defined such that when there has been noactivity in the session for the given time period, the information neednot be stored any longer.

In a particular implementation the portal structure is mobile, whichhere means that it supports access by mobile end user stations, such asfor example WAP-devices, in addition to fixed end user stations. Theportal structure includes rendering means for translatingservice/application data in a generic markup language into a differentmarkup language as used by, or understandable to, an end user station.If a generic markup language is used, particularly XML, data ofservices/applications is defined in a Document Type Definition (DTD)language with an URL attribute (Uniform Resource Locator). DTD is (here)an XML-document describing all the elements and their attributes whichare allowed in all the documents that can be seen as belonging to theparticular DTD. In one implementation an external system(service/application) with its own, or external, session managing means,comprises another portal. In a particular implementation the portalsession management operates according to the servlet session API or thesession EJBs specifications for defining basic session managementoperations. This means that the specifications can be used to get asession from an externally session-managed system. In this specificationit is also referred to as a backend system, which thus may be aservice/application which is external, at least in the sense that it isexternally session-managed. It may also be another portal with its ownexternal, (proprietary) session managing means.

According to the invention the portal session managing meansparticularly stores information relating to end user initiated actions,such as end user entering the portal, end user authentication, end useraccess of a service/application etc. into the portal storing means.

According to the invention, when an end user station requests aservice/application from the portal, a session with a portal sessionidentification is created by the portal session managing means. Therequest is subsequently forwarded to the requested service/applicationwhich, if it is an internal service/application, uses the portal sessionidentification. On the other hand, if the service/application isexternally session managed, an external session identification isgenerated for the end user, which is used in communication between theportal and the service/application. For an externally session-managedservice/application, the external session managing means stores theexternal session identification information generated for a requestingend user for a defined time period, e. g. throughout the session, oruntil the session has been “inactive” for a given time period.

When a subsequent call request is received from the portal, i. e. asubsequent call by the same end user in the same session for the sameservice/application, the generated external session identification isused to find the session in the service/application. Application data isgenerated and application information data is sent to the portal usingthe external session identification which, by the portal sessionunifying means, is converted into/mapped onto the portal sessionidentification.

In one implementation a namespace is created within the portal session,and for each accessed external service/application session, informationdata is stored within the namespace. In a particularly advantageousembodiment an external service/application, or an external sessionmanaging means, creates an external (or proprietary) session with aservice/application (proprietary) external session identification for anend user requesting access to the external service/application via theportal and introduces a metainformation tag, containing at least theproprietary or external session identification, into the data in thegeneric markup language, which is to be sent to the portal core.Particularly all data of the metainformation tag is stored in thecorresponding portal session for the requesting end user.

In a particular implementation continuous navigation is provided to enduser stations, irrespectively of where the service/application contentis located, i. e. whether it is internal or external, through theintroduction of metalinks to service/application data in a genericmarkup language, e. g. XML, to which the portal session id is added as aparameter. For this purpose the portal core comprises (first)translating means for processing such metalinks included in theservice/application data. The portal core further comprises renderingmeans with (second) translating means for transforming the data in thegeneric markup language into a markup language understood by therequesting end user station, which is mobile or fixed. Continuousnavigation as referred to above relates to a particularly advantageousimplementation which, with advantage, may be combined with the unifiedsession management as described in the present invention. The provisionof continuous navigation by means of introduction of metalinks to theservice/application data by the services/applications is described inthe copending Swedish application “An arrangement and a method relatingto access of applications/services” by the same applicant and filed onthe same day as the present invention, and the content of which herewithis incorporated herein by reference.

Thus, in a most advantageous embodiment the portal structure is mobile,and it supports access by mobile end user stations over a mobilecommunication network, such as for example GSM (Global System for Mobilecommunications), WCDMA (Wideband Code Division Multiple Access), GPRS(GSM General Packet Radio Service), UMTS (Universal MobileTelecommunications System), Bluetooth (which is a short range radiotechnology), WAP (Wireless Application Protocol) etc. Advantageously theportal structure supports access by broadband devices such as PCs, ormore generally fixed devices, as well as mobile devices such asWAP-devices.

In other terms the portal structure supports access by fixed as well asmobile end users stations using different access formats or usingdifferent markup languages for communication with the portal structure.

According to one particular embodiment a service or an application mayoptionally be provided with one or more other metainformation tags inaddition to metainformation tags containing external sessionidentification information.

Although the invention is not limited thereto, if a generic markuplanguage is used, the generic markup language may be XML. The XML-dataand possible metalinks are defined in a Document Type Definitionlanguage (DTD). A metalink tag in XML-data comprises information aboutmetalink type, a reference and addressing attribute (URL) containingservice/application location information. The translating means (of therendering means) translates XML-data by performing a transformation(XSL), i. e. the XML-data is processed together with a transformationstylesheet (XSL transformation) to produce an output format, i. e. amarkup language, appropriate for the accessing end user station, e. g.HTML (Hypertext Markup Language) for a fixed end user station and WML(Wireless Markup Language) for a mobile end user station. XSL isdescribed in XSL Transformations (XSLT) Version 1.0, which is a W3CRecommendation dated 10 Nov. 1999 and XSL Transformations (XSLT) Version1.1., which is a W3C Working draft, 12 Dec. 2000, which documentsherewith are incorporated herein by reference.

Particularly, at a subsequent access of the same service/application bythe same end user in the same session, the stored metainformationcontaining the external (proprietary) session identification isforwarded from the portal session managing means by the session unifyingmeans to the external service/application (external session managingmeans), such that the external session as indicated by the externalsession id can be found.

The invention also discloses an arrangement in a portal structurecomprising a portal core with a presentation arrangement, portal sessionmanaging means generating and handling session related information, e.g. session identifications, and storing means for storing sessionrelated information. The arrangement further comprises a sessionunifying arrangement for unifying management of portal sessions andexternal sessions generated by external session managing means managingexternal services/applications. The portal session identification (only)is used in communication between the portal and an accessing end userstation, and the external session identification information is used incommunication between the portal and the external service/application.The unifying means comprises means for mapping between portal sessionidentifications and external session identifications. Advantageouslyexternal service/application identification information is stored in theportal storing means in the respective portal session for a defined timeperiod, e. g. throughout a session. The arrangement particularlycomprises rendering means for translating service/application data in ageneric markup language into other markup languages, depending on thetype of a requesting end user station, for rendering aservice/application data output to end user stations having requestedaccess to a service/application. Particularly such generic markuplanguage is XML.

In a preferred embodiment external session identification information isprovided in metainformation tags introduced into the externalservice/application data, and more particularly the metainformation datais stored in the portal session in the portal storing means storingportal session information. The portal session identification isparticularly added to the external application/service data as aparameter.

At a subsequent request to the portal for the same externalservice/application by an end user during an ongoing session, themetainformation is included into the request by the session unifyingmeans upon forwarding the request to the external service/application,i. e. after mapping/transforming from portal to external sessionidentification.

The invention also discloses a method of session management in a portalstructure when external services/applications, which are externallysession-managed, are accessed. The portal structure comprises a portalcore with a presentation arrangement, portal session managing meanshandling session related information and portal storing means forstoring session related information. The method includes the steps of;creating a portal session with a portal session identification when anend user requests access to a service/application, unless a portalsession already exists; forwarding the request to the requested externalservice/application; creating, in or for the external service, byexternal session managing means, an external service/applicationsession, whereby an external service/application session identificationis generated unless the session already exists for the requesting enduser; whereby, in the service/application the following steps areperformed; generating service/application data; introducing informationabout the external session identification to the service/applicationdata; returning service/application data including the external sessionidentification to the portal; whereby in the portal the following stepsare performed: mapping the external session identification onto theportal session identification; storing the external sessionidentification into the portal session in the portal storing means;sending the service/application data to the requesting end user usingthe portal session identification only.

The method further includes the steps of; looking up the portal sessionin the portal storing means at a subsequent request by the end user forthe external service/application; establishing if the portal sessionrelated information contains an external session identification; if yes,forwarding the request including the external session identification tothe requested external service/application; looking up the externalproprietary service/application session in the service/application or inexternal session managing means, using the external sessionidentification; generating service/application data; adding the externalsession identification to the service/application data; sending theservice/application data with the external session identification to theportal session managing means etc. In a preferred implementation theexternal service/application generates a generic markup language, e. g.XML. Preferably the step of adding external session identificationcomprises generation of, and introduction of, a metainformation tagcontaining at least external session identification to the externalservice/application data.

The invention also discloses a method of integrating portal sessionmanagement with the external session management of an externallysession-managed system, which comprises the steps of; mapping betweenportal session identifications and external session identifications;storing information relating to external session identifications inportal storing means in a generated portal session; using the portalsession identification in communication with an end user station; usinginformation relating to the external session identification incommunication with externally session-managed systems.

DETAILED DESCRIPTION OF THE DRAWINGS

The invention will in the following be further described in anon-limiting manner and with reference to the accompanying drawings, inwhich:

FIG. 1 schematically illustrates an overview of a portal structureaccording to one implementation of the invention,

FIG. 2 illustrates a conceptual division of the presentation arrangement(layer) into a rendering functional layer and a service functionallayer,

FIG. 3A is a block diagram of a portal through which an end user firstrequests access to an external application,

FIG. 3B is a block diagram as in FIG. 3A when the end user againaccesses the application during the session,

FIG. 4 is a flow diagram schematically describing a generalimplementation of the inventive concept,

FIG. 5 is a flow diagram describing the flow when an end user accesses aportal requesting access to an external service/application when thereis no session,

FIG. 6 is a flow diagram describing the procedure when an end usersubsequently accesses the same application in the same session, and

FIG. 7 is a diagram illustrating the session mapping interactions in thesession unification procedure.

DETAILED DESCRIPTION OF THE INVENTION

With reference to FIGS. 1 and 2 an exemplary portal structure will bedescribed in a quite detailed manner. Such a portal structure may beused in the implementation of the inventive concept which is describedwith reference to FIGS. 3-7. It should also be clear that the inventionby no means is limited to be implemented on a portal as described inFIGS. 1 and 2, this portion of the description mainly being included fordescribing some exemplifying underlying concepts and the functioning ofone portal structure as such.

FIG. 1 thus shows one example on a portal structure 10 according to theinvention. The portal structure 10 comprises a portal core 1 handlingpresentation functionalities, subscription and session managementfunctionalities, a number of services and applications 2, comprising forexample personal communication services, personal information servicesand Mobile E-Commerce services. In brief it is not important which kindof services that are provided and the inventive concept is applicable toany kind of service, content and application. When explaining theinventive concept in a more detailed manner (FIGS. 3-7), when an enduser requests access to a service or an application, any service orapplication (or content) is meant and can be seen as conceptuallyincluded in the portal structure, although some of the services andapplications actually are located outside the portal structure and areprovided by any external service provider, which in this documenthowever are denoted external in case they are externally-sessionmanaged, i. e. if they are not session managed by the portal sessionmanaging means.

The portal core structure 1 further includes a layer 3 including anumber of service enabling means, also called service enablers 31-37,38A-38D. The service enablers are among other things involved inauthentication and basic services such as gateways and IPinfrastructure. In this figure some examples on service enablers aregiven such as unified messaging 31, IP infrastructure 32, AAA-Server 33,notification support 34, charging support 35 and operation andmaintenance support 36. Further examples of service enablers are mobilepositioning system 37, WAP gateway 38A, SMS-C gateway 38B, multimediaproxy 38C, mobile E-pay 38D etc. It should be clear that some of theseservice enablers are more or less mandatory, whereas others areoptional.

The portal structure is here also seen as including a connectivity or a(mobile) bearer layer comprising the mobile base stations and switchingnodes, such as BTS (Base Transceiver Station), BSC (Base StationController), MSC (Mobile Switching Center) nodes etc. Which the nodesare, depends on which mobile network access is provided over, e. g. GSM.For GPRS or UMTS corresponding nodes are included in this layer; forexample GGSN (Gateway GPRS Support Node). Whichever is the network, thenetwork is the data bearer for the portal for access of mobile devicessuch as WAP-devices (Wireless Application Protocol). In FIG. 1 it issupposed that the accessing end user station comprises a WAP-telephone5.

One example on such a portal structure is the Ericsson WISE™ Portal.

Internal applications or services can be seen as applications leveragingthe service enablers and connectivity layers to add application specificvalues to mobile Internet applications of various categories, forexample mobile services, personal communications as unified messaging ormail services, and personal information services. The information may beretrieved by the user through searches, but the information may also beprovided to the end user by means of the push technology. This is opento end user customization.

It is advantageously supposed that the portal supports access by mobileend user stations, such as WAP-telephones 5 over a mobile network.Therefore nodes or components of the relevant mobile network have to beprovided in mobile network connectivity and data bearer layer. In FIG. 1a component denoted ISP network, Internet Service Provider network, isdisclosed. This is an optional component which may be included or not.

In the layer comprising the service enablers 3 some types of serviceenablers are mandatory whereas other are not. Some of the serviceenablers are as seen as important components for providing mobileInternet functionalities. Some of the service enablers are seen as onepart of the interface components between Internet and the mobilenetwork. One component is here denoted IP infrastructure 32. An optionalservice enabler comprises the notification support 34, which generallyis an optional component enabling applications to send out filterednotifications to end users using the SMS (Short Message Service)channel, but it may also be adapted to include other channels supportingWAP technology and 3G (3GPP) technology. Charging support enabler 35 maybe provided to allow for flexibly choosing charging events. Anotherservice enabler 36 relates to operation and maintenance support andgenerally it is a mandatory component. A service enabler WAP gateway 38Ais an optional service enabler WAP gateway/proxy forming the accesspoint between the wireless world and the Internet world. It supportsmobile clients accessing the WAP gateway/proxy using GSM circuitswitched data or WAP over SMS (SMS over MAP (Mobile ApplicationProtocol)). The client uses a WAP enabled browser in the mobile deviceto connect to the WEB-server where the desired WAP application resides.Another service enabler, mobile positioning system, 37 is an optionalcomponent allowing sending the position of a user to the applicationrequesting it. Another service enabler is a multimedia proxy 38Cresponsible for transmitting multimedia data over GPRS or UMTS. Thishowever is an optional service enabling means. Also SMS-C (centre)gateway 38B is an optional component responsible for sending orreceiving, storing and forwarding short messages between mobile stationsand servers. Proprietary protocols are used for communication withapplications. Mobile E-pay 38D is a component offering the basicfunctionality for Mobile E-Commerce and it is an optional component.AAA-Server 33 is a service enabling component relating toauthentication, authorization and accounting. These functionalities maybe provided in other manners but they may also be integrated in afunctionality server, for example enabling traffic based charging andperiod charging. Such a component, either if it is split up intodifferent components or comprises a single component, which is commonfor a number of functionalities, is mandatory, and in an advantageousimplementation it is used for session management functionalities.

However, it should be clear that FIG. 1 merely shows examples on serviceenabling means that may be provided in a service enabling layer 3. Atleast some of the illustrated service enablers may be excluded, stillothers may be included etc.

The portal core, or the portal core layer, handles, as referred toabove, presentation, subscription and session management and servicetiers comprising a number of internal (and external) applicationservers. The core 1 comprises a presentation arrangement 11 whichenables mobile portal presentation on multiple devices using multipleprotocols. It may e. g. be XML driven (or more generally driven by ageneric markup language). In one implementation it is a Java and XMLdriven multimarkup language capable presentation module.

The presentation arrangement 11 comprises a rendering means (a renderingengine) which in one implementation uses XML/XSLT technologies to ensurethat information presented by services within the portal is displayed ina standardized way, regardless of which type of end user station (orbrowser) an end user uses when accessing the portal structure. Throughthe use of a generic markup language, for example XML/XSLT, the “lookand feel” of content presented to end users may be customized. XSL is anabbreviation for Extensible Style Sheet Language. The Swedish patentapplication “An arrangement and a method for presentation customizationin a portal structure”, which is an application filed on the same dateand by the same applicant as the present application, and the content ofwhich herewith is incorporated herein by reference, relates to usercustomization in a portal structure as described herein, andparticularly it is concerned with “look and feel” customization.

The functionalities within the portal core 1 and of the presentationarrangement 11 in particular will be further described with reference toFIG. 2.

The portal core 1 also includes the subscription manager. In oneimplementation subscription manager component information is stored inan LDAP (Lightweight Directory Access Protocol) directory and it ismanaged by a service called subscription manager. The subscriptionmanager includes functions for the operator to create, maintain anddelete subscriber information in the subscriber database. It alsoenables the end user of the system to subscribe to the services in thesystem. In a particular implementation a self-registration andself-service concept is supported in order to minimize costs byminimizing the workload on a customer care center. Information aboutavailable services may also be kept in the directory referred to above,and handled by the subscription manager. As a new service is enteredinto the directory, it will immediately be available for subscription bythe end users. In the directory end users can be grouped so as to makenew services available only to defined sets of end users. Thesubscription manager 12 can be interfaced with an existing customer caresystem through the application programming interface (API) it uses.

The session manager 13 is a general mechanism that can be used byapplications and services. It comprises an interface to a subsystem forkeeping track of all visitors to the portal and to provide the profileinformation of the visitors. When an end user enters thesystem/application, a session id entity is allocated and it is storedfor that particular end user until logging out of the service or whenthe end user has been idle for a preset period of time. When aparticipating application starts, it first checks if there is an activesession id for a particular user and if there is one, it would be ableto resume from where the session was broken. The session managementfunctionalities according to the inventive concept will be describedbelow with reference to FIGS. 3A-7.

Finally, the portal core structure 1 here comprises two “internal”application servers 14A, 14B and one or more external application server14C. The external application server 14C contains links to externalapplication servers running existing services. In one implementation theservice tier comprises three classes of services, of which a first isdeveloped in compliance with the portal core specifications implementedusing the portal core environment. A second service class relates toservices which not necessarily are implemented in the portal coreenvironment, such as for example an external e-mail system running on anon-portal core environment adapted to present itself through the portalcore presentation. The third service class relates to external serviceswhich do not comply with the portal core service development orpresentation architectures. This will be further explained withreference to FIG. 2.

In the following the portal core, and specifically the presentationarrangement, comprised in the presentation layer, will be morethoroughly described, first with a general reference to FIG. 2.

The service tier in one advantageous implementation comprises threeservice classes. The service class portal core service (pcoreservice)complies with the specifications of the portal core and it is used toleverage the portal core characteristics. In one implementation theservices are implemented using the J2EE IBM WEBSphere Environment (anapplication server used to develop programmatic services involvinglogic, algorithms etc.). Such services generally have three or four tierarchitectures deploying JSP (Java Server Pages) on the front end, Javaservlets and Enterprise Java Beans (EJB) in the middle layer and variousentities on the back end. The second service class are the integratedportal core services (integrated pcore services) which leverage pcorepresentation services but which are not necessarily implemented in theportal core J2EE environment, e. g. an external e-mail system running ona non-portal core environment, but adapted to present itself through theportal core presentation. The third service class, pcore externalservices, neither complies with the portal core service development norwith the presentation architectures but the services included in thisclass may e. g. be triggered to the portal core.

In one implementation there are two types of service options availablewithin the service layer. One may consist of services provided byBroadvision (CORBA) for creating optimized rule based and personalizedservices connected to commerce and retail, and optimized for contentdelivery by a matching engine operating on content, profile and businessrules. The other service type relates to programmatic services forexample requiring algorithms, logic etc. which are not easily built inan optimized content delivery system. If these services are of pcoreservice class, then they may be industrialized for IBM WEBSphere J2EEenvironment and if they are of integrated services class and running inan external service server, they are adapted to the portal corepresentation.

A service needs specifications including elements on the renderingfunctionality of the presentation layer as well as relating to theservice layer functionality, i. e. schemes and logic. The portal corepresentation architecture may, as referred to above, in one advantageousembodiment implement the J2EE architecture for the mechanisms ofcreating and employing services in specific elements or for definingservices. However, the invention is not limited to a portal structureusing J2EE and Broadvision which merely are given as examples.

The presentation layer is conceptually split-up into two tiers, onerendering layer residing in the portal core itself and a service layeravailable to any service that wants to present its content through theportal core presentation structure. The rendering layer in oneadvantageous implementation uses XML/XSLT technologies. Thereby it isalso ensured that information presented by services within the portalcan be displayed in a standardized way irrespectively of which is theend user station, i. e. irrespectively of which kind of end user stationthe end user uses when accessing the portal. Through the use of XML/XSLTit can be assured that a unified “look and feel” of content is presentedwithin the presentation space.

If XML is used as a generic markup language, a service produces anoutput in the form of an XML document formatted using structureinformation from a pcore DTD. The XML output from the service is thenused to feed the presentation engine of the presentation arrangement.The presentation engine uses pcore SS and pcore grid informationassociated with the pcore DTD of the XML document supplied by theservice to generate the desired interface. Services which do not produceXML from a pcore DTD are particularly also able to present themselvesthrough the presentation services.

As referred to earlier, the portal structure is advantageously able tohandle different devices such as WAP-phones and broadband devices suchas PCs, or the browser used thereby. A portal core structure platformand the logic in it are particularly totally separated from thepresentation layer functionality, which makes it very easy to implementsupport for all different types of clients, even voice and speechsynthesizers. By using for example XML/XSL, it is very easy to implementsupport for instance for a new type of WAP-display size. It is alsopossible to adapt the rendering process to various WEB-devices, existingand future hand-held devices, voice browsing and interactive TV.

In one particular implementation the WEB-interface is composed of squareelements also denoted bricks. A brick is a container of a service, apicture or an application, displayed on the screen of the end userstation. Using such bricks or containers, it is possible to customizethe portal. A brick is thus an application created to be used inside theportal structure, which has a link to the application. The applicationhas to provide display information to the portal when it wishes torender the brick. Advantageously a brick can appear in more than oneformat. The disposition of the bricks or containers represent a socalled brick interface. In order to enable easy navigation, theWAP-interface may in one implementation be structured in the same way.In the WEB-interface the user is presented with a list of availablebricks. Each brick contains an application, service or a backgroundpicture that can be included in the user's built WEB-site. A brick canalso be a pre-configured service from an external company or provider. ABrick-grid is a non-visual representation of a customized portal.Depending on device, the brick grid is represented in a way that is mostsuitable for the device in use. The grid can be designed in many ways aswell as the way the bricks are presented and organized, for example withtags. The brick grid is stored in a generic format and it is device/enduser station independent.

Preferably the end user authenticates himself towards the portal with aone time login which will give the end user access to all thefunctionality within the portal. Any authentication towards connected orto external content or service providers is handled by the platformsecurity system. Advantageously each application or service within theportal can be personalized to fit the needs of the end user and eachapplication can be personalized for different devices. This isparticularly advantageous when an end user wants to limit the amount ofdata sent to another end user station with limited capacity to presentlarger amounts of data, e. g. a WAP-phone. It is possible to select oneapplication more than once and to give each of the different instancesits own personalization.

Above one example on a portal structure has been described in which theinventive concept can be implemented. However, the invention as such isof course not limited to be implemented in such a portal but it is basedon the assumption that a portal structure is provided which is able toprovide end users, i. e. entities accessing the portal, with access toservices/applications. For each end user a session is created by theportal and each session contains end user specific data. Aservice/application may be external or internal. In this context aninternal application or service is defined as an application or serviceusing the session management of the portal, whereas an externalapplication or service is defined as an application or service using anexternal session management, which means that it may provide for thesession management itself, or it may be session-managed by a thirdparty.

1. A portal node within a computer-implemented communication networkproviding an end user station with access to services and applicationswherein said, services and applications include internal services andapplications and a plurality of external services and applications,comprising: a presentation arrangement for communicating data with saidend user station; a portal session managing means for generating sessionrelated information, including portal session identification, the portalsession managing means operating according to the servlet session API orthe session EJB:s specifications defining basic session managementoperations; a portal storing means for storing session relatedinformation; an external session managing means for generating externalsession identification; and a session unifying means for mapping betweensaid portal session identifications and said external sessionidentifications wherein said external session identification is used forcommunicating between said portal node and said external services andapplications and only said portal session identification is used forcommunicating between said portal node and said end user station.
 2. Aportal node according to claim 1, wherein the services and applicationsutilizing a generic markup language.
 3. A portal node according to claim2, wherein the generic markup language is XML.
 4. A portal nodeaccording to claim 2, wherein the presentation arrangement comprisesrendering means for translating service and application data in thegeneric markup language into a different markup language used by an enduser station.
 5. A portal node according to claim 2, wherein said datarepresenting services and applications in the generic markup languageare defined in a Document Type Definition (DTD) language with anURL-attribute.
 6. A portal node according to claim 1, wherein saidportal storing means stores all proprietary information associated withan external service and application and identified with a particularexternal session identification for a defined time period.
 7. A portalstructure according to claim 1, wherein said external session managingmeans comprises another portal.
 8. A portal structure according to claim1, wherein the portal session managing means stores information relatingto end user initiated actions, including end user entering the portal,end user authentication, and end user access of a service/applicationinto the portal storing means.
 9. A portal node according to claim 1,wherein said portal session managing means assigning a portal sessionidentification in response to receiving an end user request for service;and in response to determination that the requested service is internalto said portal node, using said assigned portal session identification;otherwise, said external session managing means assigning an externalsession identification for said external services and applications. 10.A portal node according to claim 9, wherein said session unifying meanscorrelates said portal session identification with said external sessionidentification allowing data provided by said external services andapplications to be forwarded to said end user station.
 11. A portal corewithin a computer-implemented communicating system for communicatingdata between an end user terminal and service providers wherein saidservice providers include internal service providers associated withsaid communication system and external service providers communicablycoupled to said communicating system, comprising: a presentationarrangement; a portal session managing means generating portal sessionrelated information, including portal session identification, the portalsession managing means operating according to the servlet session API orthe session EJB:s specifications defining basic session managementoperations; a portal storing means for storing portal session relatedinformation; an external session managing means for generating externalsession identification for communicating with said external serviceproviders; a session unifying means for unifying management of portalsessions and external sessions by allowing said end user terminal tocommunicate with said internal service providers using said portalsession identification and allowing said portal core to communicate withsaid external service providers using said external sessionidentification.
 12. A portal core of claim 11, wherein said portalstoring means stores data mapping a particular portal sessionidentification with a particular external session identification for aparticular communication session between said end user terminal and aparticular service provider.
 13. An arrangement according to claim 11,wherein that the presentation arrangement comprises rendering means fortranslating service data in a generic markup language into other markuplanguages depending on the type of a requesting end user terminal forrendering service data output to end user terminals having requestedaccess to a service into a markup language understandable by the enduser station.
 14. An arrangement according to claim 13, wherein thegeneric markup language is XML.
 15. An arrangement according to claim11, wherein that external session identification is provided in ameta-information tag introduced into the external service data and inthat the meta-information data is stored in the corresponding portalsession in the portal storing means storing portal session-information,and in that the portal session identification is added to the externalapplication data as a parameter in communication with the end userterminal, replacing the external session identification.
 16. Anarrangement according to claim 15, wherein that for a subsequent requestto the portal for the same external service by an end user terminalduring a session, the metainformation is included into the request whenforwarded from the portal core to the external service provider.
 17. Acomputer-implemented method of session management in a portal structureincluding a portal core further including a presentation arrangement,portal session managing means handling session related information andportal storing means for storing session related information, comprisingthe steps of: creating a portal session with a portal sessionidentification when an end user requests access to aservice/application, unless a portal session already exists, the portalsession managing means operating according to the servlet session API orthe session EJB:s specifications defining basic session managementoperations; forwarding the request to the requested externalservice/application if the requested service/application is externallysession managed; creating in the external session managing means anexternal service/application proprietary session identification for therequesting end user unless a session already exists; generatingservice/application data in the service/application; introducinginformation about the external session identification into theservice/application data; returning service/application data includingexternal session identification to the portal; mapping the externalsession identification to the portal session identification; storing theexternal session identification in the corresponding portal sessionmeans; sending the service/application data to the requesting end userusing only the portal session identification.
 18. A method according toclaim 17, wherein the method comprises the steps of: in the portal:looking up the portal session in the storing means at a subsequentrequest by an end user for an external service/application during thesession; establishing if the portal session related information containsan external session identification, if yes; forwarding the requestincluding the external session identification to the requested externalservice/application; in the external session managing means or in theexternal service/application: looking up the externalservice/application session; generating service/application data; addingthe external session identification to the service/application data;returning the service/application data with the external sessionidentification to the portal session managing means; in the portal:replacing the external session identification by the correspondingportal session identification; sending the service/application data tothe end user station using the portal session identification only.
 19. Amethod according to claim 17, wherein the external service/applicationutilizing a generic markup language, e. g. XML.
 20. A method accordingto claim 19, wherein the step of adding external session identificationcomprises generation of and introduction of a metainformation tagcontaining at least external session identification to theservice/application data.